-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhance iDynTree from / to Python mapping and add proper NumPy support #726
Conversation
|
5ae1586
to
1e42d1e
Compare
This PR is targeting |
Tests on Ubuntu 18.04 are failing with:
Based on https://packages.ubuntu.com/search?searchon=contents&keywords=numpy%2Farrayobject.h&mode=exactfilename&suite=bionic&arch=any I guess we need to either install |
bindings/python/CMakeLists.txt
Outdated
if(NOT IDYNTREE_USES_PYTHON_VERSION) | ||
set (IDYNTREE_USES_PYTHON_VERSION ${PYTHON_VERSION_STRING}) | ||
endif() | ||
find_package(Python3 ${IDYNTREE_USES_PYTHON_VERSION} COMPONENTS Interpreter Development REQUIRED) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as this is targeting devel
(i.e. iDynTree 2), it is ok to just support Python3 . In this context, what is the value of IDYNTREE_USES_PYTHON_VERSION
? Permit to find for different Python 3 version? I am not sure if FindPython3
works in this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we can ignore Python2 support, I'll remove IDYNTREE_USES_PYTHON_VERSION
entirely. If you want to find a specific version, you can use find_package(Python3 3.6 EXACT [...])
, however this is not the case since we just need any Python3. Done in e6b6f50.
bindings/python/CMakeLists.txt
Outdated
get_filename_component(PYTHON_DIR ${PYTHON_LIBRARY} PATH) | ||
link_directories(${PYTHON_DIR}) | ||
if(NOT IDYNTREE_USES_PYTHON_VERSION) | ||
set (IDYNTREE_USES_PYTHON_VERSION ${Python3_VERSION}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As IDYNTREE_USES_PYTHON_VERSION
is a cache variable, this is either not doing anything, or in any case something of really confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, in light of also #726 (comment) I removed it.
Checking a bit more the docs, I think we search and link the |
1e42d1e
to
6e223fb
Compare
Thanks @traversaro for the feedback!
You're right, I rebased the PR on devel. I actually think that it could work also on master as it is, but if we can ignore python2 targeting devel maybe it's better doing so.
I tried to compile and run the tests in my setup (bionic + virtualenv) and I didn't need to link that target. You're right that it's missing, maybe my system has those headers installed with apt in a already included directory. Done in 1d89ebe. |
a42617c
to
e6b6f50
Compare
Sorry, |
- From / to Numpy - From lists, tuples, ... for 1D vectors
e6b6f50
to
2ec8883
Compare
Thanks, rebased. Let's wait CI. |
@traversaro How should we handle the CLA? Either @francesco-romano signs it or I substitute the cherry-picked commit. |
I will force the check, as Francesco Romano already signed the CLA in another form. |
Can you update the CHANGELOG with the changes contained in this PR? Main thing to mention: dropped Python2 support, removed |
47812dd
to
0ad3c61
Compare
Updated the changelog in 0ad3c61. I noticed that the |
Thanks! |
This is now require since robotology/idyntree#726 .
After only one year from #484 (comment) I finally managed to fix and refactor that PR.
I don't know if it is a wise choice, but I tried to maintain the same APIs that @francesco-romano developed at that time. I implemented a somehow cleaner version of the original pull requests that 1) does not require to write any low-level CPython code and 2) exploits the existing typemaps provided by
numpy.i
. I cherry picked the original Python test.Particularly, I exploited 2) in such a way that the memory of the objects mapped to numpy is handled by Python. When an object gets deleted, its memory is buffered for being garbage-collected [3].
Contrarily to #484, I used a mixture of C++ wrappers functions and Python extend in the SWIG file. Luckily, the recent refactoring and new inheritance scheme of #704 (see #704 (comment) for more details) helped reducing the cases.
Resources